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SUBJECT Simulating the RR-CDU Interface When the HR is in the 

SLEW or AUTO (not IGC) Mode, i n pmES/PCI LABORATORY. 

i SUMMARY , 

Research has been done by the staff of the PCI Laboratory 
to find a way to reproduce without an actual radar pedestal the 
RR-CDU interface condition that exists when the KR is moded to 
SLEW or AUTO. Mr. Bvorkin devised a setup using a Resolver 
Circuit Tester (Apollo GSE) kindly loaned by AC Electronics that 
causes the CDU's to slew at essentially 6,4 KC. This setup was 
enabled during a nominal G Mission descent using the LUMINARY 1A 
Plight Program. The alarm conditions experienced by Apollo 11 
were essentially reproduced. 

The software performance of this simulation wasc analysed and 
it is concluded that this input to the HR CDU's should permit a 
valid verification of -the fix (PGR 848) in LUMINARY IB." Purther, 
we belejlve that this run also provides hybrid simulator confirm¬ 
ation of the diagnosis of the alarm condition in Apollo 11. 



ilSGUS-SIOlj - h-g <PH7. SETUP 


«-. nri! , nf the recommendation in .LAV-500-940 

LsearcHed several possibilities for injecting 


Mr. Marty B^rlcln researched seve 

signals i^to the front ends (A/D' 


DU channels to 


the CDTJ ! s +° a .£ effectively slew speeds (6.4 KC). This in- 

yestigati 0 n°cS3uded that use of are-solver would he the best arrang- 
ment. ThaSks to the cooperation of the AG Electronics Site support 
(group at ppA obtained the loan of ^ a Resolver Circuit Tes oe.,, 
a ptece of Anoilo Ground Support Equipment. 


Moni 


ice of Apollo Ground Support Equipment. 

This equipment was connected to the HR CDU* s and 
torin® q S P th° CLIPS on the DS-KY (V1&N72) showed < 


CA power 
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variation 3 of the~shaft and trunnion angles. In order.to get a better 
look at the effect, we set up an EMemory loaded specia_ doym._isx. 
This program Is prepared by Mr* Jimmy Glass man following tne ±orir.^v 
of the so-called" 70 A word list used in the IMU Performance Test 
K START Tapes (-K00081). In this case it displays an ID word, o DP 
words each containing shaft and trunnion CDU counters, and. two worc .3 
of channels. In this way we have essentially a 20 ms (.the interval 
between downlink' transmissions)- monitor on the angles. Examination 
of some printout of this list (Quick Look) showed total excursions 
of about"l3 deg. almost entirely at 6.4 KC.It is estimated ohao tne 
reversals which were at slow rate resulted in an average 15/* pulse 
loss compared to a continuous 6*4 KC slewing. .However, iu is ±elt 
that this is representative of the condition in tne vehicle, con¬ 
verting to central processor time loss from botn CDU channels this 1 
1 yjo instead of 155&* 


Since the PMES/FCI LABORATORY was coming back on line prepar- 
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to doing LUMINARY IB testing using LMY99 (LUMINARY 1A, the Apollo li 
Plight Program) it seemed useful to run a nominal descent such as in 
Apollo 11, with Marty’s setup inputting the HR CDU’s. No attempt was 
made to reproduce exactly the Plight’s IC’s or to follow exactly znc. 
trajectory (flight path). Our plan was to.call up the VI 0 N 08 monitor 
normally, leaving them on a while to see if an alarm condition was 
induced. If one occurred we would reestablish the.monitor.. 

The idea here was that if’we had the basic situation, we could get 
more samples of the alarms. The spare location-/r26-in the Descent an 
Ascent downlist was patched to display AlMCADR so we could see which 
Job v/as being called at overflow. Of course it.was understood tsjht 
the Job belng^t overflow might just be a victim rather than one the 
v/as in trouble. In the end we would go to P 66 rather than going 
automatic all the way. Again, there was no attempt to follow veil’s 
profile in P 66 . 
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DISCUSSION OP THE PERFORMANCE OP THE SIMULATION rtUN 

The performance of this' run, summarised in TABLE 1, was in signij 
icant agreement with the Apollo 11 landing on the moon based on ••.ain 
we have seen to date. The following references are pertinent: 

LAV-500-940; Clint Tillman; Program Alarms in Powered Descen.u~Ap< 

-U 

MIT/IL Letter AG#370-69; George Cherry; Exegesis of the 1201^and 

1202 Alarms' Which Occurred During me 
Mission G Lunar Landing. 


Ho alarm occurred in the first V16r!68 monitor for a period longs, 
than the 12 sec in the flight so V57S was executed. Therea.i.ter, i<-O s 
alarms came after Vl 6 N 68 's were entered in P 63. The lasr monitor 
started in ? 63, overlapped into P 64: a 1201 occurred. A second 120 
came in-P 64 without DSKY entry as in the flight. Einax^y, ^ere was 
one more 1202, but unlike the flight this was in P 66 * and. at+ermg, 


There were no so-called multiple alarms-thams, one right on top 
of another or in fast succession, say at'the ra^e of SERVICER (every 
2 sec). There were no 1203*s. The RR CDUFail indication, Ch30B07, 
was present throughout the run. This should be* if the resolver setup 
was working. Trajectory performance data has not been reviewed, but 
jthe Software Restarts did not cause any other'perturbations noticeabl 
[to the Pilot (Dick Brent) and the landing seemed nominal. 

DISCUSSION QP BOMB SOFTWARE OBSERVATIONS 

Having ALMCADR* patched onto the'downlist-permits to obtain deeoe 
insight into the situation and to confirm some _of the comments in 
George*s AG Letter. Seven alarms were induced. All were triggered by 
legitimate Jobs g* c gording to the Job Table appended to the letter. 


Three amplifications to George*s table must be noted: 


1.) MAKEPjjAY is a PINDVAC or NO VAC Job depending on whether or not it 


is making a flashing display. In P 63 and P 66 it displays V06N63 and 
V06N60 respectively and so is a NOVAC. This agrees with our run. In 
P 64 it starts out with a PV06N64 and so is a PINDVAC.'The flash i 


a 


request or cue to the Astronaut to enable LPD (the Landing Point Desi 


nator). If he does (with a PRO), the display reverts to V06N64 and 
MAKEPiAY is once again a HO VAC. 


2.) There is an additional PINDVAC Job, RODCOMP (Priority 22). It is 
established every second only in the Rate of Descent Program, P 66. 
3«) LRHJOB supervises taking one Landing Radar altitude sample every 
2 sec. While it is true the radar is sampled for 80 ms, the*overall 
process of sampling and transferring takes 90 ms. And up to another 
10 ms may be needed due to the relative timing of the request to the 
LGC clocks. The Job may sleep for up to 100 ms. 

LRVJOB is similar, but it supervises 5 "consecutive** samples of a 
single LR velocity parameter every 2 sec. This makes a block of time 


about 0.5 sec long during which the Job is sleeping in the UOVAC queu 


Let us consider the situations at the 1201 alarms (No VAC areas). 
There was one in the flight, in P 64 prior to enabling LPD, so L1AKEPL 
was a PINDVAC at that point. In the simulation there Were two 1201 *s 
both in P 64. LPD was not enabled in this run. The other PINDVAC Jobs 
possible in P 64 were SERVICER and HIGATJOB. HIGATJOB is essentially 
a. one-shot affair, supervising the re-positioning of the LR. In the 
flight the LR was re-positioned about 5 sec after P 64 was displayed 
and about 40 sec before the AC 1201. In the simulation-see TABLE 1-t 
LR repositioned 8 sec after P 64 and 20 sec before the first 1201. 
HIGATJOB could have contributed little to these alarms. While the fir 
AC 4201 in tne simulation occurred with the V16N68 monitor running, 
note that MONpO calls are NOVACVs and could not lead directly to an 
overload of.the VAC area queue. Of course the job does represent an 
additional time load on the central processor. 

I belejive this evidence substantiates George *s conclusion that th 
1201 alarm codes were due to SERVICER not getting enough time on the 
central processor to complete its work and so becoming multiple sched 
uled. A ubiquitous SERVICER, in conjunction with the NOVAC class Job 
could also overload the larger coreset area queue, leadingA'1202 sAar 
codes in P 63 and in P 64, after enabling LPD. In P 66 SERVICER does 
not have to do guidance, bu t RODCOHP now requires a corese t every 
second. The overall loading^ must be~moreA Lin P .66*1 since in on 
case-the flight-there was no alarm while fin another-the simulation- 

there was one 1202 after about 64 second's, a,nd o 
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*A note of caution in decoding the bank constant word of ALMCADR. 

The EXECUTIVE routine only saves the caller’s FRANK . It does not ' 
supply the contents of SBANK or FEXT,Channel T, so if FRANK indicates 
a Superbank the two possible alternates must each be checked. This‘ ws 
the case with the MONDO call. 




Kie Software Restart approach, to handling internal computer sched 
uling overloads consists of two major steps: 

; ix Terminating all activity that has come under its control. This ca 
; include normal programed activity* required for automatic operatio 
"externally” requested activity such as Crew selected displays an 
Extended Verbs; and unnecessarily scheduled activity. 

2) Re—initiating only the normal, baseline, programed activity. 

The visible objective is to maintain a baseline program activity that 
will sustain at least minimum mission performance-the inner curative 
mechanism may vary considerably with the situation. Two cases are ill 
ustrated here. We see from the flight data and this simulation that 
in P 63 there was a conflict of three interests: high baseline, activi 
an unplanned loss of about 15/£ of available central processor time, 3 
a fairly time consuming external display request (the V16N68 monitor) 
In this case the restart system saved the day by killing the external 
request as necessary. 


The curative mechanism at work in the P 64 case was much more 
sophisticated and the struggle more dramatic. Here the contending 
elements must have been a baseline program activity even somewhat hi, 
er than in P 63 and the unplanned for time loss. And now the effect 


of several restarts was to slightly reduce the amount of purposeful 
work done by the central processor when considered over a larger int 
val than the 2 sec SERVICER period. (This was accomplished, of cours< 
just by knocking down all the scheduled Jobs .and Tasks and starting 
again.) This might be visualized as occasionally adjusting the S.SRVIi 
period, lowering its rate while trusting that guidance-control would 
not suffer noticeably. 


The amount of time overload that could be handled by the restart 
system is hard to say. It is immediately dependent on the dynamic rat 
in the guidance at the time and their interaction with control(PAP) 
dynamics and/or other unadjustable periods and time constants. 

The "restart period" in P 64 in the flight was about 28 sec, an 
order of magnitude greater than SERVICER 1 s. Apparently, flight perfor 
ance was not perturbed. G-eorge T s letter discusses briefly the idea of 
programing the guidance to be based on a Servicer period that would 
vary automatically to accommodate work load fluctuations. Polks may 
recall that in November 1968 The MIT/lL prepared PCR 650 "Variable 
Guidance Period", which covers this. It was for LUMINARY 1A and was 
disapproved January 21 1969. 


PMES/PCI LABORATORY 


Some folks may also recall that during PMES/PCI LABORATORY testin 
of SUNBURST, the uM-1 Plight Program, we subjected LIP 11 (BPS 2) to a 
heavy_profile of random restarts. Domjan and Beardsley of the Perform 
ance Analysis Group, who were studying the Guidance-Control Interact! 
proolem, looked at one such run and concluded that the restarts had 
improved matters. It would be hard to directly project this to the 
present since there have been significant changes. For example: tie 
guidance phases were modified; FINBCBUY/, the guidance-control interfa 
routine, is new;the BaP itself is new;SUNBURST did not drive the 
Tr» U Tvi display meters or the "altitude/ altitude rate meters 

t n 1 t r- e effect of restarts during descent guidance appeared to be 
somewhat the guidance-control loops. MIT/lL analysis of 
01 interact ion prior to the release of LUMINARY 1A , le 
°- ' tiie guidance equations to compensate for comoutati 


pci 731^ le ’ PII ' IDCDUW > and attitude- control lags (as 


specified in 







CONCLUSIONS 

Jerkin's resolver setup provides an input to the EE. CI)U f s 
x^a.t adequately simulates the vehicle configuration when the oan 
control is in SLEW or AUTO. 

This arrangement should be used to verify the fix (PGR 843} in 
LUMINARY IB. ' 


2 . 


The diagnosis of the alarm problem in Apollo 11 has been verified 
m a very comprehensive hybrid simulator-The PMES/PCI LABORATORY. 






















